METHOD FOR RADIO ACCESS BEARER RECONFIGURATION 
IN A COMMUNICATIONS SYSTEM 

Field of the Invention 
The present invention relates generally to the field of wideband code 
division multiple access (W-CDMA) systems, and more particularly, to a 
method for performing radio access bearer renegotiation/reconfiguration. 

Background of the Invention 
Quality of service (QoS) is an important consideration in wireless 
communication systems. Different types of service require different levels of 
quality. For example, a mobile telephone user that is engaged in a voice call 
with a network will likely require a higher quality connection (in terms of delay) 
than a user that is web surfing on his or her mobile telephone. Likewise, a 
user engaged in a web surfing session will likely require a better bit error ratio 
than a user engaged in a voice call. In accordance with existing 3 rd 
Generation Partnership Project (3GPP) standards, when a user equipment 
(UE), such as a mobile telephone, requests service from the core network 
(CN), a UMTS bearer service and underlying radio access bearer (RAB) 
service is set up for the requested service. This protocol is described in 
sections 6.1, 6.1.1, 6.1.2 of 3GPP TS 23.107 v4.0.0 (2000-12). Presently, 
the RAB includes nineteen (19) parameters for the service such as traffic 
class, maximum bit rate, and guaranteed bit rate, to name a few. The 
parameters characterize the required QoS for the requested service. 

The RAB parameters are defined in section 9.2.1 .3 of 3GPP TS 
25.413 v4.0.0 (2001-03). The traffic class is defined as the type of 
application for which the Radio Access Bearer service is optimized. The 
maximum bit rate is defined as the maximum number of bits delivered by the 
Universal Terrestrial Radio Access Network (UTRAN) and to the UTRAN at a 
Service Access Point (SAP) within a period of time, divided by the duration of 
the period. The guaranteed bit rate is defined as the guaranteed number of 
bits delivered at a SAP within a period of time (provided that there is data to 
deliver), divided by the duration of the period. In accordance with sections 
8.2 and 9.1.3 of TS 25.413, a RAB Assignment Request message with 



specified RAB parameter values is sent from the CN to a Radio Network 
Controller (RNC) in the UTRAN to inform the RNC of the QoS expected by 
the CN for a RAB. If any of the RAB parameters need to be changed, RAB 
negotiation or renegotiation/reconfiguration is performed. RAB negotiation 
5 refers to the exchange that occurs at the establishment of a RAB before 

settling on RAB parameter values. RAB renegotiation/reconfiguration refers 
to the exchange that occurs after the establishment of a RAB to request 
change of some or all previously agreed upon RAB parameter values. 

In 3GPP Release 1999 standards, such as TS 24.008, v3.7.0 (2001- 
10 03), section 6.1 .3.3 on PDP context modification procedure, QoS 

renegotiation for a service can be initiated by the CN and the UE. This does 
not allow efficient management of radio resources, because although the 
RNC actually manages the radio resources, it is not allowed to initiate QoS 
13 renegotiation through RAB renegotiation/reconfiguration to account for 

|i|5 changed radio conditions. Failure to perform RNC initiated RAB 
5J{ renegotiation/reconfiguration can result in radio network overload, dropped 

ill calls and degradation of the quality of remaining calls. For example, if the 

J RAB for a call initially specifies a maximum bit rate of 16 kbps, the RNC may 

9 need to lower the maximum bit rate to 12 kbps due to changed radio 

lm conditions. Currently, the RNC is unable to initiate 
p renegotiation/reconfiguration of the RAB to effect this change which could 

result in a dropped call. Thus, there is a need for a method of RNC initiated 
RAB renegotiation/reconfiguration to decrease the occurrence of radio 
network overload, dropped calls and degradation of call quality. 

25 

Brief Description of the Drawings 
FIG. 1 is a block diagram showing the architecture of a UMTS system 
that can be used to implement the preferred embodiment of the present 
invention. 

30 FIG. 2 is a message flow diagram that includes the preferred 

embodiment of the RNC initiated RAB negotiation and 
renegotiation/reconfiguration method of the present invention. 
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Detailed Description of the Drawings 
The present invention generally provides a method for an RNC initiated 
RAB renegotiation/reconfiguration. A new message (RAB Modify Request 
message) and modifications to old messages (RAB Assignment Request 
message, RAB Assignment Response message) are exchanged between the 
RNC and the CN in order to implement the method. In the preferred 
embodiment, the method is implemented in a UMTS system, however the 
method can also be implemented in any wideband code division multiple 
access (W-CDMA), code division multiple access (CDMA), Enhanced Data 
for GSM Evolution (EDGE) or General Packet Radio Service (GPRS) or 
Global System for Mobile Communication (GSM) wireless systems that 
require renegotiation/reconfiguration of RABs. Referring to FIG. 1, a 
simplified UMTS architecture 100 that can be used to implement the present 
invention is shown. As known in the art, the UMTS architecture 100 includes 
a CN 102 coupled to a UTRAN 104 through an lu interface 108. The UTRAN 
104 includes an RNC 105. The UTRAN is coupled to a UE 106 through a Uu 
interface 110. Further details regarding the UMTS architecture 100 shown in 
FIG. 1 can be ascertained from sections 5 and 6 of 3GPP TS 25.401 V4.0.0 
(2001-03). 

Referring to FIG. 2, a message flow diagram for the preferred 
embodiment of the method of the present invention is shown. At the 
establishment of a service (e.g., voice call, web surfing session, etc.) between 
the CN 102 and the UE 106, the CN 102 will send a RAB Assignment 
Request Message (RARQM) to the RNC 105. This is represented as step a 
in FIG. 2 The CN 102 will assign a RAB ID to the RAB associated with the 
service and will specify certain RAB parameter values expected for the RAB, 
as known in the art. However, in accordance with the present invention, the 
RARQM will also include a field for the CN 102 to designate RAB parameters 
as negotiable/renegotiable and provide a range or set of acceptable values 
for some or all of the parameters specified. For example, the CN 102 may 
specify in the RARQM a guaranteed bit rate of 16 kbps for the RAB. The CN 
1 02 may also specify an acceptable range for the guaranteed bit rate, such 
as 8 kbps to 16 kbps. At step b, the RNC 105 sends a RAB Assignment 
Response Message (RARSM) to the CN 102. The RARSM informs the CN 



102 what the RNC 105 is able to assign (i.e., which parameter values it is 
able to provide). For example, if the RNC 105 is unable to meet a 
guaranteed bit rate of 16 kbps, it may respond that it is able to meet 12 kbps, 
which is in the acceptable range designated by the CN 102. 
5 After a service is established between the CN 102 and the UE 106, the 

RNC 105 monitors radio resources to determine if radio conditions have 
changed which could in turn affect the quality of the service. For example, 
changes in the UE's position may affect the quality of a call. In such a case, 
the RNC 105 may need to change one or more of the RAB parameters 
10 currently in place for the call. In accordance with the present invention, at 

step c in FIG. 2, the RNC 105 initiates the RAB renegotiation/reconfiguration 
procedure by sending a RAB Modify Request message (RMRM) to the CN 
'\ 102. The RMRM includes a "RABs To Be Modified" field (or Information 

\Q Element (IE)) that is used to identify the RAB ID of the RAB for which 

;?? 15 parameters need to be modified and to identify the RAB parameter values 

that need to be modified. For example, the voice call may have a RAB ID of 
m "1" and the parameter value to be modified may be the guaranteed bit rate. 

!L, Whereas, the RNC 105 may have been able to provide a guaranteed bit rate 

m of 12 kbps at the establishment of the call, changed radio conditions may 

: vj20 require the RNC 105 to lower the guaranteed bit rate to 10 kbps. 

Upon receipt of the RMRM, the CN 1 02 will determine whether it will 
accommodate the request. At step d, the CN 102 may send another RARQM 
informing the RNC 1 05 whether it accepts the request to lower the bit rate to 
10 kbps. Later, if radio conditions improve, the RNC 105 may send another 
25 RMRM to the CN 102 to request an increase in the guaranteed bit rate. 

RMRMs, RARQMs and RARSMs may continue to be exchanged between the 
CN 102 and the RNC 105 as long as there are parameters to be changed. 

Those skilled in the art will recognize that various modifications and 
variations can be made in the apparatus of the present invention and in 
30 construction of this apparatus without departing from the scope or spirit of this 
invention. For instance, the method of the present invention has been 
described with reference to modifying the guaranteed bit rate parameter of a 
particular RAB. The method is equally applicable to any of the RAB 
parameters. 



-4- 



